1. Field of the Invention
The present invention relates to a computer assisted credit management system including a collection system, a decision engine, and a promise management system, and, more particularly, to a promise management system which interfaces to the decision engine and to the collection system and which recommends payment promise terms to the user of the system.
2. Description of the Related Art
Computer assisted credit management systems, including computer assisted collection systems, are known in the art. Generally, a collection system, such as a full collections system, may include a variety of components, such as a Collection Engine, a Decision Engine, a User Interface (for either a collector or customer), and other components. A collector is a user of a collection system whose primary job is to use a collection system to facilitate collecting payments on accounts needing collection action, such as delinquent accounts, overlimit accounts, special status accounts, etc. Collection systems generally include parameters, such as collection policy parameters. Collection policy parameters are used by credit granting institutions to specify how a collection system implements the collection policy of the credit granting institution.
Examples of computer assisted collection systems include the Computer Assisted Collection System™ (or CACS®), by American Management Systems, Inc. (AMS), and its several versions including CACS® Enterprise, Computer Assisted Collection System™ for Government (including TRACE™), and CACS®-Telecom.
CACS® Enterprise is explained in the CACS® Enterprise Product Profile, March 1998 by AMS, incorporated herein by reference. Prior versions of computer assisted collections systems such as CACS® Enterprise have been in use for many years, with the CACS® Baseline having been in use since approximately 1984, with approximately 200 collections organizations worldwide using various interfaces, such as a CACS® Enterprise 3270 interface, an AS/400™ interface, and PowerBuilder™ (for CACS®-T and CACS®-G).
CACS® Enterprise, such as CACS® Enterprise 7.0, is a member of the AMS series of credit management software that supports all phases of credit operations, from initial application processing through servicing and accounting to collections. Available exclusively through AMS, each system can be installed individually, collectively, or in any combination to address evolving support requirements.
The Computer Assisted Collection System™ for Government is explained in the CACSPlus® Product Profile (Client/Server version) by AMS, August 1997, and incorporated herein by reference. CACS®-Telecom is explained in the CACS®-Telecom Product Profile by AMS™, September 1998, incorporated herein by reference. In addition, there are mainframe versions of CACS®, having a 3270™ interface thereto, such as TRACE™.
Computerized tracking of promises to pay is also known in the art. CACS® Enterprise records promises to pay. More particularly, CACS® Enterprise supports recording of promises on collection accounts. In the computer assisted collection systems of the related art, such as CACS® Enterprise, the user (for example, the collector), provides the system with arrangements of repayment of an outstanding debt, referred to as promises to pay, by the account holder. CACS® Enterprise relies on customer account data and collection parameters entered into the collection system by the system administrator to validate reactively the collector-entered promise terms, including promise amounts, dates, and schedules.
Generally, in the computer assisted collection system of the related art, the arrangements of the promises to pay (such as payment amount and frequency of payment) are negotiated between the collector and the account holder, and are then input into the computer assisted collection system of the related art for verification against criteria previously established and provided therein. If the negotiated arrangements of the promises to pay are not within the criteria provided in the computer assisted collection system, an error message is displayed to the collector indicating that the arrangements are not accepted by the computer assisted collection system. The collector must then re-negotiate the arrangements with the account holder, and enter the re-negotiated arrangements into the computer assisted collection system for verification. The process of negotiation and verification continues until the arrangements of the promises to pay are acceptable to the collector, the account holder, and the computer assisted collection system.
FIG. 1 shows an example of a collection cycle 12 for a payment promise using CACS® Enterprise, as an example using a collection system 20 of the related art. The collection system 20 of the related art may be provided in a mainframe or a client/server environment.
As shown in FIG. 1, in operation S10, an accounting system downloads collection accounts to the collection system 20 of the related art for collection activities. Then, in operation S12, the collector requests of the collection system 20 an account. Based upon the account returned from the collection system, in operation S14, the collector then negotiates with the customer (or account holder) the arrangements of the promise to pay. Next, in operation S16, the collector records in the collection system 20 the payment arrangements (or agreement) reached with the customer. The collection system 20 then verifies whether the payment arrangements meet the criteria provided in the collection system 20, as shown in operation S18. If there are errors in the payment arrangements (i.e., the payment arrangements do not satisfy the collection parameters stored in the collection system), then the part of the collection cycle of the prior art beginning with operation S14 is repeated until there are no errors in the payment arrangements.
In the meantime, control is returned to operation S12 and the next account is obtained by the collector from the collection system.
FIG. 2 shows a screen layout 30 from a current CACS® Enterprise 3270 mainframe display, for a particular account. As shown in FIG. 2, the screen layout 30 includes account holder demographics 32, account summary data 34, account data view and scripts (including information such as the date the account was opened, the credit limit, the date of the last bill, the balance, the amount in dispute, the total amount due currently, the amount that is over the credit limit, the amount that is late, and the aged data) 36, and an account history 38 (including previously-made promises) which includes an area for the collector to interact with the collections system.
Promises in CACS® Enterprise are now discussed. Collectors can make arrangements with account holders for one or two payments (standard promises), or for a series of weekly, bi-weekly, or monthly payments (long-term promises or deferred payment arrangements). Standard and long-term promises, as well as deferred payment arrangements, are described in further detail in the following paragraphs.
Standard Promises
The CACS® Enterprise mainframe screen display includes a Coded Collection History line having fields such as PROMISE 1 and PROMISE 2. Collectors may enter a single promise by filling an amount and date in the PROMISE 1 fields of the Coded Collection History line. Collectors may enter two promises by filling in both the PROMISE 1 and PROMISE 2 fields. CACS® Enterprise validates the promise amount and date entered according to parameters entered in management control tables.
Long-Term Promises
CACS® Enterprise considers any payment arrangement extending for more than two payments as a long-term promise. To enter long-term promises, collectors enter the amount and date of the first payment, along with the amount of the long-term promise amount for the weekly, biweekly or monthly payment.
Deferred Payment Arrangement
A Deferred Payment Arrangement (DPA) is another type of promise CACS® Enterprise supports. Collectors set up a DPA to record a weekly, biweekly, or monthly promise for the current bill plus an agreed-upon monthly payment which is applied to the outstanding delinquency.
In a typical collection system of the related art, delinquent accounts are arranged into groups, then into queues within the groups, in accordance with rule-based criteria. Each collector is provided by the collection system with a next account from a particular queue. For example, CACS® Enterprise divides accounts into groups based upon parameters such as front end parameters, midrange parameters, and other group parameters, which are discussed herein below.
Queues of accounts are also built by CACS®. The queues include accounts requiring the same next action, e.g., send a letter, contact customer for a payment promise. Rules are defined to control the movement of accounts between queues. Queues are defined for special purposes, such as supervisor review. If a collector cannot come to acceptable terms within parameters on a payment promise, the account is routed to a supervisor queue for out-of-tolerance promise approval/denial. Approved payment promises are put into the proper queue to wait for promise fulfillment; denied payment promises are returned to the collector for re-work.
Known in the art are systems which offer recommendations of promises for a particular account using a single account's data. More particularly, known in the art is a promise advising system in which a decisioning component evaluates and recommends suggested payments based on decision trees. Decision trees, or decision engines, are also known in the art.
A concept previously proposed, although not embodied, includes a promise advising process which evaluates and presents recommended payment amounts using account and/or customer data.
A problem with credit management systems, and collection systems in particular, of the related art is that several iterations between the collector and the account holder may be necessary to establish an arrangement of payment acceptable to the collector, the collection system, and the account holder, because the related art collection systems verify payment promises entered by the collector against predetermined criteria as a reactive check. Therefore, reaching agreement between the collector, the collection system, and the account holder is a hit or miss process.
Another problem with credit management systems, and collection systems in particular, of the related art is that payment promise options are not presented to the collector by the collection system prior to negotiations between the collector and the account holder.
Still a further problem with systems of the related art is that recommended best payment options are not offered.
A further problem with credit management systems, particularly with collection systems, of the related art is that a collector must first enter a promise date and amount, and submit same to the collection system for validation of keying errors and collection policy adherence, without knowing whether the promise date and amount adhere to the collection policy provided in the collection system.